Wireless M-Bus to NB-IoT - Send-Once Approach
Integration manual for the ACRIOS Systems converters ACR-CV-101NI-W-D2 and ACR-CV-101NI-W433-D2 for Wireless M-Bus smart meters readout.
Introduction
Send Once protocol is a simple, easy to deploy and integrate solution for smart metering. It is especially useful if you want to gather data from large amount of devices. Then only major trade-off is the lack of two-way communication, which, however is still possible by use of Multimode configuration. Check the following article if you wish to know more.
This article covers the following topics:
- Send-Once principle
- Lua script - the configuration
- Uplink commands
- Payload and its parsing
This manual describes a use of the following Lua script.
First, we look at the principle of this Lua script and how it is beneficial for quick and easy deployment, then there is explanation of static parameters in the script, which can be adjusted and finally there is a full example of communication between an ACR-CV unit and the server along with an explanation. In case you look for detailed description of the communication protocol used in the described script, please refer to this intergration manual.
Send-Once Principle
Key Principles
- The converter listens to the meter transmissions during a configured time period and creates a table of known meters to prevent multiple instances of sending the same meter payload.
- The converter captures the payloads and sends them to the server via NB-IoT.
- The converter plans automatic readouts based on the configuration.
- The converter starts gathering data at a specified time, which can be delayed based on a time spread parameter. This function allows the reduction of peak load on the server by time spreading the uplinks.
- Additionally, the converter periodically sends a "beacon" message, awaiting a response from the server for configuration updates, although the response is not mandatory.
The converter can listen to and read data from meters operating in wireless T and C modes simultaneously.
Boot-up and scheduled actions diagram
The system starts by booting up and determining the initial wake-up reason, specified by the nextWR parameter in the script, which could be for either beacon reporting or data gathering. It then performs the corresponding task and goes to sleep until the next scheduled wake-up.
Upon waking up, the system reassesses the wake-up reason, schedules the next wake-up time based on the upcoming beacon or gather times, and repeats the process accordingly.
If you press the button on the device, it will wake up and send a beacon report immediately, regardless of the scheduled wake-up time. This doesn't affect the scheduled wake-up time, which will still occur as planned.
Communication with a server diagram
The ACR-CV converter periodically sends a Beacon Report (0xF0 0xFF) to the server to indicate it is ready to receive commands. The server may respond with a Downlink commands for specific actions (e.g., restart, update), but it is not required to respond.
The converter periodically sends gathered data to the server using the Send Once Data (0xF0 0xFE) message. The server can optionally send an Acknowledge (0x08) message back to the converter. If no actions are taken or configurations are changed, the beacon will timeout. This ensures continuous data exchange and command execution.
Parameters
If you purchase Miotiq SIM cards from us, you don't need to manually configure any settings. The script comes with default settings tailored for Miotiq SIM cards, ensuring seamless integration and operation. This makes the setup plug-and-play, with all parameters pre-configured (check for availability here) but any local equivalent service should do, check this section for further details. If you are unsure about this, feel free to contact us at acrios@support.com.
-- denotes a comment in the script.
ver="1.3" -- version of the script
----- CONFIGURATION -----
-------- NB-IoT ---------
proto = "UDP" -- protocol used for communication
port = 4242 -- port used for communication
APN = "auto" -- APN for the SIM card
PLMNID = 0 -- PLMNID for the SIM card
ip = "192.168.0.20" -- IP address of the server
reinitOnWakeGather = 1 -- 1 for reinitialization of the NB Iot module before gathering
----- Comunication ------
withIMSI = 0 -- 1 if you are using our backend, with different SIM card provider than Miotiq
expectAnswer = 0 -- 1 if you expect an answer from the server
rxtout = 35000 -- NB IoT send maximum execution time in milliseconds
nonewdatatout = 4000 -- NB IoT send maximum delay between data chunks on reception
------- Filtering -------
allowedDevTypes = {0x02,0x03,0x04,0x06,0x07,0x08,0x0A,0x0B,0x0C,0x0D,0x15,0x16,0x28} -- empty = all allowed
------- Start-up --------
nextWR = 1 -- 1 for starting with gathering, 0 for starting with beacon
-------- TIMING ---------
-- Gathering scheduler --
workdayOnly = true -- true for workdays only, false for all days
numberOfDays = 3 -- number of days/workdays since end of month
startHour = 10 -- hour of start of the readout
randomizeSeconds = 7200 -- up to 7200s~2hrs of delayed start since startHour
--- Periodic sending ----
pDaysDef = 7 -- period of days for sending data
pHrsDef = 0 -- period of hours for sending data
pMinsDef = 0 -- period of minutes for sending data
---- Mode switching -----
SsecDef = 120 -- S mode timeout
TsecDef = 120 -- T mode timeout
MsecDef = 120 -- M mode timeout
------- Timeouts --------
speDef = 30 -- seconds per device timeout
iftDef = 10 -- interframe timeout
--------- Other ---------
noComWdg = 5*24*3600*1000 -- no communication watchdog - resets the device if no communication is received in the specified time (5 days in milliseconds)
beaconTDef = 12*4 -- sending beacon interval (12*4*15min = 12h)
--- CONFIGURATION END ---
Example of Gathering
Timing diagram of the gathering process - day
The diagram aligns with the parameters specified in the script. You can observe that the beacon is sent periodically, which corresponds to the beaconTDef parameter, indicating a 12-hour interval for sending beacons. Additionally, the gathering process uses a spread function and starts later than the set time, as defined by startHour and randomizeSeconds, allowing for up to a 2-hour delay in the start time. This configuration ensures that the system sends beacon reports regularly and initiates data gathering with a randomized delay.
Timing diagram of the gathering process - month
The diagram shows that data gathering occurs only on the last three working days of the month, consistent with the numberOfDays and workdayOnly parameters. The ACR-CV converter sleeps most of the time but wakes up for specific activities, including sending beacon reports and send once data at regular intervals as specified by script parameters.
Modifying the Script for Different SIM Card Providers
If you wish to use a SIM card coming from a different provider than Miotiq, modify the script accordingly.
1a. Set these parameters to the values provided by your SIM card provider.
...
APN = "auto" -- <- change this (but keep the commas, e.g.: "cdp.iot.t-mobile.nl")
PLMNID = 0 -- <- change this (e.g.: 20416)
...
1b. Or set the values as following for the automatic selection.
...
APN = "auto"
PLMNID = 0
...
The automatic selection has to be supported by the SIM card provider.
2. If you are using our backend, set IMSI to 1.
...
withIMSI = 1
...
Uplink - Payloads Sent by the Converter
Beacon Report (0xF0 0xFF)
Beacon report provides information about the device connectivity and some additional details.
| Example | Description | Size | Byte Number | Value |
|---|---|---|---|---|
| 0xF0 0xFF | Command byte | 2B | 1-2 | |
| 0x0D | Relative counter | 1B | 3 | 13 |
| 0x01 | Reason | 1B | 4 | 1 |
| 0x04 0xA9 0x00 0x00 | Uptime in | 4B (little endian) | 5-8 | 43268 [s] |
| 0x04 0xA9 0x00 0x00 | Since last TAU | 4B (little endian) | 9-12 | 43268 [s] |
| 0xA7 0x19 0x86 0x0D | Last gathering timestamp | 4B (little endian) | 13-16 | 226892199 [s] |
| 0xA3 0x27 0x86 0x0D | This beacon timestamp | 4B (little endian) | 17-20 | 226895779 [s] |
| 0x32 0x2E 0x32 | Script version | 3B (ASCII) | 21-23 | 2.2 |
| 0x00 | Zero terminatition | 1B | 24 | |
| 0x0E | Signal | 1B | 25 | 14 [CSQ units] |
| 0x30 0x0E | Battery voltage | 2B (little endian) | 26-27 | 3632 [mV] |
| 0x38 0x36 0x38 0x33 0x33 0x33 0x30 0x33 0x35 0x30 0x33 0x37 0x31 0x32 0x32 0x00 | IMEI | 16B (ASCII) | 28-44 | 868333035037122 |
| 0x00 | Time Until Battery at 3250 mV | 1B | 45 | 0 [s] |
| 0x02 0x0D 0x06 | Firmware Version = 2.13.6 | 3B | 46-48 | 2.13.6 |
| 0x05 0x04 0x00 0x00 | Absolute Awake Time | 4B (little endian) | 49-52 | 1029 [s] |
| 0x5F 0xA0 | NB-IoT Local Area Code | 2B (little endian) | 53-54 | 41055 |
| 0x21 0x30 0x10 0x00 | NB-IoT Cell ID | 4B (little endian) | 55-58 | 1060897 |
| 0x68 0x10 0x00 0x00 | NB-IoT Tracking Area Update (TAU, T3412) | 4B (little endian) | 59-62 | 4200 [s] |
| 0x3E 0x00 0x00 0x00 | NB-IoT Active Timer (T3324) | 4B (little endian) | 63-66 | 62 [s] |
| 0x00 0x00 0x00 0x00 | NB-IoT Module Last Sleep Failure Timestamp | 4B (little endian) | 67-70 | 0 |
| 0x00 0x00 0x00 0x00 | NB-IoT Module Sleep Failure Event Count | 4B (little endian) | 71-74 | 0 |
| 0x03 | Device Reset Reason | 1B | 75 | 3 |
| 0x00 0x00 0x00 | Reserved bytes | 3B (little endian) | 76-78 | |
| 0x16 | CPU Temperature | 1B | 79 | 22 [°C] |
Last gathering timestamp → 226892199 + epochBase = 1678491399 → To UTC → 10/03/2023
This beacon timestamp → 226895779 + epochBase = 1678494979 → To UTC → 11/03/2023
epochBase = 1451602800 - 3600
Note that the Lua script version may exceed 3 bytes in size and it is terminated by a null character.
Time Until Battery → 0 means that the device did not had to wait before sending NB-IoT message (higher values mean weaker battery).
NB-IoT Module Last Sleep Failure Timestamp (since 1.1. 2016) → 0 means event did not happen since boot
NB-IoT Module Sleep Failure Event Count → 0 means event did not happen since boot
Device Reset Reason:
- 0 = unknown
- 1 = OBL
- 2 = Pin
- 3 = Brown Out
- 4 = SFTRST
- 5 = independent watchdog
- 6 = window watchdog
- 7 = LPWRRST
- 8 = FWRST
Send Once Data (0xF0 0xFE)
This Lua script is identified by this message.
| Example | Description | Size | Byte Number |
|---|---|---|---|
| 0xF0 0xFE | Command byte | 2B | 1-2 |
| 0x... | Raw wM-Bus data | xB |
Downlink - Payloads Sent by the Server
Send a Configuration (0x02)
This command sends configuration to the device.
| Example | Description | Size | Byte Number |
|---|---|---|---|
| 0x02 | Command byte | 1B | 1 |
| 0x06 | Total gather time | 1B | 2 |
| 0x00 | Gather time S mode [s] | 1B | 3 |
| 0x00 | Gather time T/C mode [s] | 1B | 4 |
| 0x00 | Wake up period [Days] | 1B | 5 |
| 0x00 | Wake up period [Hours] | 1B | 6 |
| 0x0F | Wake up period [minutes] | 1B | 7 |
| 0x1E | Gather time M mode [s] | 1B | 8 |
| 0x01 | Inter-frame timeout [s] | 1B | 9 |
| 0x30 | Beacon period [quarter] | 1B | 10 |
Total gather time - This is a time defining how long should device gather payloads, calculated by multiplying the entered number by 10 minutes.
Gather time S, T, and M mode - This is a time in seconds defining for how long the device should receive the data in S, T, or M mode.
Inter-frame timeout - This is a timeout between frames sent by the device. For example, the inter-frame timeout will trigger sending process after reaching given time limit during gathering.
Beacon period - This defines how many quarter-hours device sleeps before sending a beacon message (messages between gathering process).
Payload Parsing
The payload can be both parsed by our backend, then we only send you the parsed data you need, or you can parse it and work with the data the way you need.
The converter sends a payload starting with the bytes 0xF0 0xFE, followed by captured wM-Bus payloads. For parsing, delete the first two bytes (command bytes) and pass the payload to the wmbusmeters parser. Public GitHub wmbusmeters repo.
Payload Parsing Example
Payload from the converter could look as following (feel free to test it on the example):
F0FE1844AE4C4455223368077A55000000041389E20100023B0000
1. Remove the first two (command) bytes.
1844AE4C4455223368077A55000000041389E20100023B0000
2. Put the rest of the payload to the wmbusmeters parser.
3. Click on the "Analyze" button to parse the payload.
Parsed Payload JSON
A successfully parsed payload looks as following.
{
"media":"water",
"meter":"iperl",
"name":"",
"id":"33225544",
"max_flow_m3h":0,
"total_m3":123.529,
"timestamp":"2024-08-13T07:23:41Z"
}
Conclusion
The Send-Once protocol allows for a simple solution for smart metering, the following things have been covered in the article.
- Quick integration with help of Miotiq SIM card or using a provider of your choice.
- Simple configuration of the device via Lua script with minimal need for manual changes.
- Consistent and effective process of data gathering from multiple meters.